Before
diving deep into a technical discussion, you should understand some key
concepts and terminology that are extremely important for understanding
the design and architecture of ACS. This section introduces some new
terms and redefines some existing terms in the ACS context.
1. Identity Provider
An identity provider
manages your identity and provides an authentication service for client
applications. Identity providers authenticate users and issue Security
Assertions Markup Language (SAML) tokens (defined in a moment). SAML
tokens contain user IDs and other identity properties of the user
(claims). Examples of some identity providers are Windows Live ID,
Geneva Server, Google Accounts, Yahoo ID, and Sun.
2. Relying Party
The relying party is the
application that relies on the claims issued by ACS to authorize a user
and release appropriate access to the user. As a developer, you're
primarily concerned with developing a relying party application that
receives a SAML token filled with claims from ACS. You then process
these claims in the relying party to provide appropriate access to the
end user.
3. Security Token (SAML token)
A SAML token is an XML message
consisting of sets of claims digitally signed by the issuing authority.
The token is issued by a Secure Token Service (STS). The ACS and
relying party both process claims from SAML tokens.
4. Secure Token Service (STS)
An STS is a subsystem
responsible for building, signing, validating, cancelling, renewing,
and issuing SAML tokens. An STS may support one or more of these
features. It typically implements the protocol defined in the WS-Trust
specification. Identity providers and ACS both have STS capabilities.
An R-STS is a resource STS
that acts as an intermediate claims-transformation service to transform
input claims from a partner STS to output claims specific to your
application. This model is popular in extranet and cross-enterprise
applications. ACS is an R-STS because it transforms input claims from
identity providers to output claims. You can build your own STS and
R-STS using Microsoft's Geneva Framework.
5. Request for Security Token (RST)
Every relying party
requires a unique set of claims it can process. RST is the request made
to an STS to acquire these claims to an STS. For example, a requestor
may make this request to ACS to acquire claims for a relying party.
6. Request Security Token Response (RSTR)
The response sent by an STS to the RST is called an RSTR. This request contains the SAML token with claims signed by the STS.
7. Claim
A claim consists of
information about the user or role interested in accessing an
application (or relying party). A claim can have any information about
the user depending on the configuration of the identity provider and
ACS. A typical ACS scenario involves three kinds of claims:
User claims:
When a user sends a request for a security token to ACS, the request
contains claims like the username, password, domain name, and so on,
which are usually required for authentication.
Input claims:
When the user is authenticated with the identity provider, the identity
provider issues a SAML token. The SAML token usually contains input
claims to the ACS. These input claims may contain user claims as well
as additional claims introduced by the identity provider in the SAML
token.
Output claims:
ACS examines the input claims from the SAML token issued by the
identity provider and maps them to output claims. ACS translates input
claims into application- (or relying party–) specific output claims and
includes them in the token that the relying party can use to authorize
users and give appropriate access. For example, an input claim
"Username: tejaswi_redkar" may map to an output claim "Role: Domain
User." The relying party reads the Role as Domain User and provides
Domain User privileges to the user. Input claims are mapped to output
claims as a part of ACS configuration exercise covered later in this
chapter.
8. Identity Federation
Identity federation is a set of
mechanisms, standards, and patterns that define different ways of
sharing identity information between domains. It reduces
identity-maintenance costs and also simplifies software development
because you don't have to design and maintain a separate identity store
within the application. Federated identities also ease single sign-on
between applications running in different domains and/or enterprises.
9. Windows Identity Foundation (Geneva Framework)
The Windows Identity
Foundation is a Microsoft product used to create claims-based
applications and services. You can build your own STS using the Windows
Identity Framework if existing products don't fulfill your application
requirements. The Windows Identity Framework simplifies the development
of cross-domain security scenarios. It provides a framework for
building passive (web browser-based) as well as active (Windows
Communications Foundation) clients that support identity federation
across a wide variety of clients and servers. ACS uses the Geneva
Framework to provide STS capabilities. Geneva Server, Microsoft's
next-generation claims-based identity federation server, is also built
using the Geneva Framework.
10. Active Directory Federation Server (ADFS 2.0) (Geneva Server)
Geneva Server is a
Microsoft product that provides STS functionality to Active Directory
or any identity provider. It's the next version of Active Directory
Federation Services (ADFS) and supports a claims-based identity model.
It enables the creation of single sign-on between on-premises and cloud
applications using the claims-based identity model. By definition,
Geneva Server implements the protocol defined in the WS-Trust
specification and so provides interoperability with other products like
Sun OpenSSO and Novell Access Manager. Geneva Server supports not only
passive clients like web browsers but also active stand-alone clients
built using the Windows Communications Foundation (WCF).
11. Web Resource Authorization Protocol (WRAP) and Simple Web Token (SWT)
ACS implements the
REST-friendly Web Resource Authorization Protocol (WRAP) that defines
the Simple Web Token standard. The token issued by ACS adheres to the
SWT specification, which you can find in the WRAP profiles on the OAuth
web site at http://groups.google.com/group/oauth-wrap-wg.
SWT tokens are HTTP form encoded key-value pairs signed with an
HMAC-SHA256 cryptographic key. ACS always emits an SWT for different
types of input tokens (such as SAML), so the relying party can always
expect an SWT from ACS.
